Skip to content

fix: generate macros for all subpackages#16955

Draft
PawelWMS wants to merge 4 commits into3.0-devfrom
pawelwi/macro_gen_fix
Draft

fix: generate macros for all subpackages#16955
PawelWMS wants to merge 4 commits into3.0-devfrom
pawelwi/macro_gen_fix

Conversation

@PawelWMS
Copy link
Copy Markdown
Contributor

@PawelWMS PawelWMS commented Apr 30, 2026

Related to #15578.

Summary

Fixes a bug in versionsprocessor where the generated macros.releaseversions file only contained macros for the default (top-level) package of each spec, missing all subpackages with their own version, release, or epoch. Also fixes a related bug where every macro for a given spec was keyed off the spec file name, so subpackages with names different from the spec name effectively never received their own macros (each subpackage would just overwrite the default package's %azl_<spec>_* macros).

Bug 1: only the default package was queried

In processSpecFile() (toolkit/tools/versionsprocessor/versionsprocessor.go), the spec query was issued with rpm.QueryHeaderArgument (--srpm):

packages, err := rpm.QuerySPEC(specFile, sourceDir, `%{NAME}: %{evr}\n`, buildArch, defines, rpm.QueryHeaderArgument)

The --srpm flag instructs rpmspec to return only the source package header. Even though the surrounding code loops over packages expecting one entry per built RPM, the query only ever returns a single line for the SRPM's own NEVR. As a result, no %azl_<subpackage>_* macros were emitted for any subpackage declared via %package — only the default package got macros.

This was raised during the original review of #15578 (review comment) but the switch to --builtrpms was not applied, only the query format and regex changes.

Bug 2: subpackage macros used the spec file name

processPackageVersionString derived the macro name from the spec file's base name (e.g. kernel.spec%azl_kernel_*) and then iterated over every queried package. Even after fixing Bug 1, every subpackage of a given spec would still write to the same %azl_<spec>_* macros, repeatedly overwriting the default package's values. Subpackages whose names differ from the spec name (e.g. kernel-headers, ca-certificates-shared, mlnx-ofa_kernel-devel) never produced their own dedicated macros.

Fix (toolkit changes)

  • Switch from rpm.QuerySPEC(... QueryHeaderArgument) to rpm.QuerySPECForBuiltRPMs. This makes rpmspec return one line per binary RPM that would be built from the spec, including all subpackages with their individual epoch/version/release.
  • Derive each macro name from the actual package name parsed out of the %{nevra} output, instead of from the spec file's base name. Each subpackage now gets its own %azl_<subpackage>_* set of macros.
  • Reuse the existing rpmSpecBuiltRPMRegex / RpmSpecBuiltRPMRegex from rpmssnapshot by promoting it into internal/rpm (along with its index constants), and extend it to capture the optional epoch and to split version and release into separate groups.
  • rpmssnapshot now consumes the shared regex and keeps its existing RepoPackage.Version shape (epoch:version-release) by recombining the split groups.
  • processPackageVersionString no longer needs the spec file name or the dist tag: the package name comes from the regex, and the release no longer carries the dist tag (dist is its own capture group now), so the manual strings.Replace(release, distTag, "", 1) is gone.
  • Lifted the per-package error context out of processPackageVersionString and into the caller (processSpecFile), where the spec file name is still in scope.
  • Existing call sites passing --srpm for arch checks etc. are untouched.

After the fix, e.g. ca-certificates.spec yields macros for ca-certificates, ca-certificates-shared, ca-certificates-base, ca-certificates-tools, and ca-certificates-legacy — each with their own %azl_<subpackage>_version / _release (and _epoch when non-zero) — instead of just the default package.

Spec consumer updates

Because the macro names are now keyed off the built RPM's name rather than the spec file's base name, any consumer that referenced a %azl_<spec_basename>_* macro for a spec whose default top-level package is not actually built had to be updated. The only such case in the corpus is mlnx-ofa_kernel-hwe.spec, which produces only mlnx-ofa_kernel-hwe-modules and mlnx-ofa_kernel-hwe-devel (no default mlnx-ofa_kernel-hwe RPM, since the top-level package has no %files section).

The 10 spec consumers that referenced the (no-longer-produced) %azl_mlnx_ofa_kernel_hwe_{version,release} macros now reference %azl_mlnx_ofa_kernel_hwe_modules_{version,release} instead:

  • HWE OOT modules: SPECS/{srp-hwe,iser-hwe,isert-hwe,mlnx-nfsrdma-hwe,xpmem-hwe}.spec
  • Their signed counterparts: SPECS-SIGNED/{srp-hwe-signed,iser-hwe-signed,isert-hwe-signed,mlnx-nfsrdma-hwe-signed,xpmem-hwe-modules-signed}.spec

All other %azl_*_* macros currently in use across the corpus (%azl_kernel_*, %azl_kernel_hwe_*, %azl_mlnx_ofa_kernel_*) refer to packages that do have %files sections in their producing spec files, so they remain valid.

Tests

  • Moved the regex-only tests for RpmSpecBuiltRPMRegex from rpmssnapshot_test.go into rpm_test.go, where the regex now lives.
  • Updated versionsprocessor_test.go for the new processPackageVersionString signature (NEVRA input, no specFileName/distTag arguments). Added a noarch case and an explicit subpackage-name assertion in TestProcessSpecFile_WithSubpackages, which now verifies distinct %azl_multipkg_*, %azl_multipkg_devel_*, and %azl_multipkg_libs_* macros.
  • Updated rpmssnapshot_test.go for the expanded regex (epoch group added, version/release split) and added an epoch-bearing input to TestGenerateResults.
  • All affected packages (internal/rpm, pkg/rpmssnapshot, versionsprocessor) pass with go test. The full toolkit/tools test run is otherwise green; the only failure is internal/pkggraph/TestReferenceDOTFile, which fails identically on origin/3.0-dev and is unrelated to this PR.

@PawelWMS PawelWMS requested a review from a team as a code owner April 30, 2026 06:58
@microsoft-github-policy-service microsoft-github-policy-service Bot added Tools 3.0-dev PRs Destined for AzureLinux 3.0 labels Apr 30, 2026
@PawelWMS PawelWMS marked this pull request as draft April 30, 2026 18:38
%global target_kernel_release %azl_kernel_hwe_release
%global target_mlnx_ofa_kernel_version %azl_mlnx_ofa_kernel_hwe_version
%global target_mlnx_ofa_kernel_release %azl_mlnx_ofa_kernel_hwe_release
%global target_mlnx_ofa_kernel_version %azl_mlnx_ofa_kernel_hwe_modules_version
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switch to the correct name of the macro after the toolkit update. Not an actual change to the version passed during the build, thus no release bump.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3.0-dev PRs Destined for AzureLinux 3.0 Packaging Tools

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant